Business rules are statements that define or constrain some aspect of a business. They can have one or more conditions that resolve to either true or false, and one or more actions that can be performed. The actions may be performed if all conditions are satisfied by external data provided as facts. A fact is basically a set of data that conforms to a given structure. In business terms, the structure may comprise such objects as a purchase order record, a customer record, credit card information, etc. Business rules typically are intended to assert business structure or to control or influence the behavior of the business. Business rules thus may be thought of as describing the operations, definitions, and constraints that apply to an organization. It will be appreciated that business rules may apply to people, processes, corporate behavior, and/or computing systems in and/or across one or more organizations, and may be put in place to help the organization(s) achieve its/their goals.
In the context of a Business Rules Management System (BRMS), for example, business rules are user-defined statements that typically reside within rule engines. A rules engine typically is a software and/or hardware system that is configured to execute one or more business rules in a runtime production environment. Business rules in the BRMS context generally are formalized so that they left-hand sides that test for various conditions of elements within predefined data structures, and right-hand sides that perform various operations. These operations may include, for example, modifying data elements of the predefined data structures, invoking web services, sending email notifications, and/or the like. As facts (e.g., data that correspond to the predefined structures) are asserted into the rule engines, they typically are evaluated by the left-hand sides (LHSs) of the rules and, if the conditions are satisfied, the right-hand sides (RHSs) of the rules are triggered. Thus, the LHS part of a rule represents the “if” part(s) that include the conditions that test data elements, whereas the RHS of a rule represents the “then” part(s) and indicates what actions, if any, result when the LHS evaluates to true.
The majority of current, commercially available rule engines support inferential processing of the rules. Others additionally support sequential processing. See, for example, Frank Olken et al., eds., Rule-based Modeling and Computing on the Semantic Web, Springer Press (2011). With inferential processing, rules are evaluated in no particular order and, thus, inferential processing supports a pure declarative representation of business rules. Modification of data elements by the right-hand side of a rule can cause other rules to be evaluated and potentially fired when their left-hand sides test the same values that have been changed. By contrast, sequential processing involves a rule order to be specified (e.g., by a user) and, in most currently available products, reevaluation of rules will not occur when data elements are modified by the right-hand sides. Thus, in sequential processing, rules within a decision table (discussed below) can be ordered sequentially and, at runtime, will be evaluated in the specified order. Metaphors (e.g., easy to understand representations of sets of rules such as, for example, decision tables, decision trees, etc.) within a rule set can also be ordered sequentially.
Some engines have additional processing modes, such as IBM's WebSphere ILOG JRules. This engine offers a Fastpath mode that is an augmented sequential compilation and execution of a rule project. See also Jérôme Boyer and Hafedh Mili, Agile Business Rule Development: Process, Architecture, and JRules Examples, Springer Press (2011), discussing in detail the sequential and Fastpath algorithm used by JRules, and explaining how to determine which processing mode (inferential, sequential, Fastpath) is best for a given rule application. Other vendors/rule engine combinations include, for example, Fair Isaac Corp.'s Blaze Advisor, Apache Open Source's DTRules, and Red Hat's JBoss Drools.
It is believed that the state of the art related to business rule technology is changing, e.g., to provide different modes of engine execution. Historically, inference execution mode has dominated the technology. For example, the Rete algorithm (which is an efficient pattern matching algorithm for implementing production rule systems) has been widely used among rule engine vendors to support rule execution and inference processing. Authoring rules was primarily performed with inferential processing in mind, and there was no way to specify any other type of execution. Today, rule engine vendors are supporting sequential processing.
Sequential processing may be supported in a number of different ways. In a first approach, using salience, a priority is placed on rules within an inference based engine. In a second approach, a framework is built around the engine that captures facts before they are asserted into the Rete-based engine. The rules are then evaluated sequentially using a separate algorithm. See also Barbara von Halle and Larry Goldberg, eds., Business Rule Revolution: Running Business the Right Way, Happy About (2006), noting that sequential processing has recently been adopted by rule engine vendors, and that sequential processing sometimes bypasses the Rete algorithm that emulates event-based processing while at the same time significantly increasing performance.
The inventors of the instant application have noticed a common trend among currently available products and approaches. In particular, the processing mode must be specified when authoring the business rules. In most cases, the default mode is inferential. However, if sequential is desired, it must be specified during design. When the processing mode is specified during design time, the rules and other necessary artifacts are generated to support only that mode. Thus, it will be appreciated that currently available products seem to be limited in the sense that the execution mode must be specified at design time, and once the mode has been set, it cannot be changed during rule invocation (e.g., at runtime).
Unfortunately, however there are disadvantages associated with requiring that the processing mode only be specified during rule authoring/design. A first disadvantage relates to the fact that rules generally are grouped on their own individually or within metaphors such as decision tables or decision trees. These metaphors themselves can be grouped within rule sets. Internally, the individual rules, metaphors, and rule sets are maintained within rule modules. These modules can be invoked independently from external applications.
Assume the following facts for the purposes of explanation. Consider that a rule module (RuleModuleA) has been authored, and is resident within a rule base for a given rule engine, RuleModuleA is invoked by 100 different external applications. RuleModuleA was authored to be processed sequentially. Now, one of the external application users has determined that it would be better if the rules within their decision table or rule set were executed inferentially. If the processing mode of the decision table or rule set is modified to support this one external application, it will potentially break the other 99 external applications.
It will be appreciated that duplication of effort is required to support two different external applications that require the same set of rules, where one decision table or rule set is required to be processed inferentially and the other sequentially. FIG. 1 illustrates a decision table (DecisionTableA) being saved as a rule module (RuleModuleA). A decision table is a precise yet compact way of representing conditional logic, and it is well suited to business level rules. A decision table may be thought of as being similar to an Excel spreadsheet, where conditions are specified as LHS columns and actions are specified as RHS columns and where each row in the table represents a separate rule. A rule module is a contained set of rules and instructions, and rule modules typically are insulated from other modules. As shown in FIG. 1, within the design/authorizing environment, DecisionTableA is saved as RuleModuleA, which is either inferential or sequential, but not both.
After authoring, RuleModuleA is deployed to the runtime environment that hosts the rule engine. Deployment places the rule module into a rule base, as well as into the rule engine. The rule base is a repository where rules are stored for a given rule engine. FIG. 2 illustrates how external applications invoke RuleModuleA from FIG. 1 in an illustrative runtime environment. The external applications generally are not aware of the underlying modules and instead only know about the metaphors or rule sets. An invocation layer directs their requests to the right module. Since Appl1, Appl2, and Appl3 all invoke DecisionTableA (RuleModuleA), they will all be affected if the processing mode for the module is changed from sequential to inferential, or vice versa.
Thus, it will be appreciated that there is a need in the art for systems and/or methods that overcome these and/or other disadvantages, thereby reducing the need for the rule designer to specify a particular processing mode at design time.
One aspect of certain example embodiments relates to enabling rule designers to specify a particular processing mode at runtime by, for example, optionally passing the processing mode as a parameter during rule invocation. A default processing mode can be utilized in certain example embodiments, e.g., where no processing mode parameter is passed. This approach may in certain example embodiments free designers from having to tie invocations to a particular processing mode at design time.
In accordance with certain example embodiments, a method of configuring a business rules management system (BRMS) including a business rule engine that executes one or more business rules in a runtime environment is provided. User input indicating that at least one rule metaphor is to be created is received in connection with a user interface operating on a computer, with each said rule metaphor including a representation of a set of rules. At least two metaphor rule modules for each said rule metaphor are generated via at least one processor, with the metaphor rule modules for a given one rule metaphor respectively supporting different ways the set of rules represented therein can be invoked at runtime. User input indicating that at least one rule set is to be created is received in connection with a or the user interface operating on a or the computer, with each said rule set being associated with at least one created rule metaphor. At least two rule set rule modules for the at least one rule set are generated via at least one processor, with the rule set rule modules for a given one rule set respectively supporting different ways that rule set can be invoked at runtime.
In accordance with certain example embodiments, there is provided a method of operating a business rules management system (BRMS) including a business rule engine that is configured to execute one or more business rules in a runtime environment. The rule engine includes plural invokable rule modules provided to handle different respective invocation types for an associated predefined rule module. A request to invoke a predefined rule module stored in the rule engine, at least one fact and/or an indication of at least one fact that is needed by the rule engine in invoking the requested predefined rule module, and an indication of an invocation type for the requested predefined rule module, are received from an application. It is determined which invokable rule module associated with the requested predefined rule module should be invoked based on the received indication of the invocation type. The invokable rule module is invoked, in connection with at least one processor of the BRMS, in dependence on this determination. Output from the rule engine is output to the application.
In certain example embodiments, non-transitory computer readable storage media tangibly store instructions that, when executed by at least one processor of a computer, may perform one of these and/or other configuration and/or operation methods.
Similarly, in certain example embodiments, a computer system including at least one processor and a memory may be configured to execute these configuration and/or operation instructions (e.g., as stored on the non-transitory computer readable storage medium(s)).
In accordance with certain example embodiments, a computer system for configuring a business rules management system (BRMS) including a business rule engine that executes one or more business rules in a runtime environment is provided. A user interface is configured to receive user input indicating that (a) at least one rule metaphor is to be created, each said rule metaphor including a representation of a set of rules, and (b) at least one rule set is to be created, each said rule set being associated with at least one created rule metaphor. At least one processor is configured to generate: at least two metaphor rule modules for each said rule metaphor, the metaphor rule modules for a given one rule metaphor respectively supporting different ways the set of rules represented therein can be invoked at runtime; and at least two rule set rule modules for the at least one rule set, the rule set rule modules for a given one rule set respectively supporting different ways that rule set can be invoked at runtime.
In accordance with certain example embodiments, a business rules management system (BRMS) is provided. Processing resources include at least one processor and a memory. A business rule engine is configured to execute, in connection with the processing resources, one or more business rules in a runtime environment, with the rule engine including plural invokable rule modules provided to handle different respective invocation types for an associated predefined rule module. A network interface is configured to receive, from an application, a request to invoke a predefined rule module stored in the rule engine, at least one fact and/or an indication of at least one fact that is needed by the rule engine in invoking the requested predefined rule module, and an indication of an invocation type for the requested predefined rule module. The processing resources are configured to at least: determine which invokable rule module associated with the requested predefined rule module should be invoked based on the received indication of the invocation type; invoke the invokable rule module in dependence on the determination; and cause output from the rule engine to be transmitted to the application over the network interface.
While the above description focuses on business rules and corresponding Business Rules Management Systems (BRMSs), it will be appreciated that example embodiments of the present invention are not limited to business aspects. Rather, one skilled in the art will appreciate that rule management systems (RMSs) are quite extensively employed in a number of technical applications. Examples include the controlling and monitoring the correct behavior of distributed computing systems (e.g., service-oriented architectures (SOA) or event-driven systems), the management of a computer-controlled assembly line in a factory, and/or the like. Thus, it will be appreciated that certain example embodiments disclosed herein are equally applicable to such technical rule-based environments.
These features, aspects, advantages, and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.